Gemeinsame Benutzung von M2LIB und MagicLib 4.x
===============================================
Die MagicLib von Peter Hellinger besteht aus einem residenten Kernel, der
allen Programmen zur Verfgung steht, und einer Bibliothek, die als
Schnittstelle die Funktionen des Kernels in der jeweiligen Programmiersprache
zur Verfgung stellt ('ne Art "shared library"). Damit ein Programm diese
benutzen kann, mu es sich explizit an- und abmelden. Die Prozeduren
"DosSystem.exit()" und "DosSystem.Exit()" beenden normalerweise den Proze,
ohne da eine Abmeldung beim Magic-Kernel erfolgt. Dies geschieht
insbesondere auch, wenn die Funktionen der ISO-Bibliothek eine Exception
auslsen ("EXCEPTIONS.RAISE()"), denn hierbei wird intern "exit()" ausgefhrt.
Mit Hilfe des Makros __MAGICLIB_TERM__, das am Anfang des Implementationsmoduls
'DOSSYSTE.IPP' definiert werden kann, wird erreicht, da ein Hauptproze, der
(explizit oder implizit durch eine Exception) "exit()" oder "Exit()" aufruft,
die Funktion "M_Appl.ApplTerm()" der MagicLib ausfhrt, so da er sich korrekt
abmeldet. Damit sollte es keine Probleme geben, M2LIB und MagicLib gemeinsam
zu benutzen.

Beendet sich ein Programm nicht ordnungsgem beim Magic-Kernel, z.B. wegen
eines Absturzes, knnen keine weiteren Programme gestartet werden, die
Magic benutzen. Mit dem der MagicLib beiliegenden Programm MAGICLR.PRG
kann allerdings auch ein nachtrgliches "Abmelden" erreicht werden, so da
dann weitere Programme gestartet werden knnen.

Was das Verhalten des Magic-Kernels bei Threads betrifft, z.B. ob sich
ein Thread, der mit "fork()" erzeugt wurde, separat beim Kernel an- und
abmelden mu, wie das auch mit dem separaten appl_init/appl_exit bei normalen
GEM-Programmen der Fall ist, darber kann ich nichts sagen. Das ist allerdings
auch weniger ein Problem von M2LIB, sondern eher das der MagicLib. Deren
Dokumentation sagt darber allerdings nichts.

Die MagicLib-Module benutzen teilweise die zum M2-System gehrende
Speicherverwaltung 'Storage' um Datenstrukturen aufzubauen. Damit nicht zwei
unterschiedliche Speicherverwaltungen benutzt werden, und weil das zum
M2-System gehrende Storage schwerlich Thread-fest ist, schlage ich vor,
den Import von 'Storage' durch den Import von 'ISOStorage' zu ersetzen.
Im einzelnen sollte auch darauf geachtet werden, welche Prozeduren der
MagicLib die Speicherverwaltung verwenden, denn auch hier gilt, da
solche dynamischen Datenstrukturen nicht von mehreren Threads gemeinsam
manipuliert werden drfen (-> THREADS.TXT). Leider steht auch darber nichts
in der MagicLib-Dokumentation.

Mit Hilfe der Prozedur "M_Appl.InstallTermproc()" lassen sich auch in der
MagicLib Modulterminierungen hnlich wie mit "DosSystem.atexit()" installieren.
Diese werden beim Aufruf von "M_Appl.ApplTerm()" vor der Abmeldung beim
Magic-Kernel ausgefhrt. Aus der Sicht von M2LIB sind dies
Systemterminierungen (siehe auch THREADS.TXT), die immer dann ausgefhrt
werden, wenn der Hauptproze mit "exit()" oder "Exit()" beendet wird. Im
Gegensatz dazu werden mit "atexit()" installierte Terminierungsroutinen
nur bei "exit()" ausgefhrt und zwar nach der Abmeldung vom Magic-Kernel.

Bei der MagicLib gibt es ein Modul 'Portab', das, zumindest auf einem
TOS-Dateisystem, den gleichen Namen wie das M2LIB-Modul 'PORTAB' besitzt.
Um Konflikten aus dem Weg zu gehen, schlage ich vor, 'Portab' umzubenennen,
z.B. in 'M_Portab'.

Man sollte darauf achten, da beim bersetzen der MagicLib die gleichen
Compileroptionen wie bei der M2LIB verwendet werden, wie z.B. die Gren von
INTEGER/CARDINAL-Typen oder die Funktionsrckgabe ber Stack oder Register.

Bei MM2 mu bei der bersetzung der MagicLib der Platz fr die Bezeichner
erhht werden, z.B. mit /I30000.
